System and Method for Automatically Selecting Encoding/Decoding for Streaming Media

ABSTRACT

Media content is encoded based on network quality of service parameters. For instance, quality of service parameters for a network between a media server and a media client are determined by a system. The system selects an encoder based on a list of decoders available at the media client and the quality of service parameters, and encodes at least a portion of the media via the encoder. The system can further determine settings for the encoder based on a media type, and encode the media via the encoder according to the settings. The system can detect when the media client moves to a new network, detect new quality of service parameters, and select a new encoder based on the list of decoders available at the media client, the media type, and the new quality of service parameters.

RELATED APPLICATIONS

The present application is a continuation of, and claims the benefit ofpriority to each of, U.S. patent application Ser. No. 15/946,250, filedApr. 5, 2018, which is a continuation of U.S. patent application Ser.No. 13/299,970 (now U.S. Pat. No. 9,942,580), filed Nov. 18, 2011, thecontents of which applications are hereby incorporated by referenceherein in their entireties.

TECHNICAL FIELD

The present disclosure relates to media delivery and, more specifically,to optimizing media encoder selection based on network conditions.

BACKGROUND

Many variables come in to play when streaming media, particularly videomedia, over a network from a media source to a media playback client.One main variable is network quality, which is, in fact, a collection ofdifferent variables. For example, inconsistent bit rates, jitter,latency, packets arriving out of order, and other Quality of Serviceparameters can wreak havoc on the client's ability to play back media ina high quality, smooth, pleasing manner.

In existing media streaming approaches, a media provider uses a mediaencoder corresponding to a media decoder at a client. The media providerand the client negotiate, such as in a handshake, to determineapproximate network conditions and an expected baseline of networkquality. If the network conditions change (i.e. deteriorate or improve),the media provider changes parameters of the encoder to respond to thechanges, such as lowering the bitrate of the media streamed from themedia provider to the client. These changed parameters can negativelyimpact the video playback quality at the client, introducing videocompression artifacts. Further, network conditions can degrade so farthat the client is unable to display any meaningful image. As more andlarger types of media are streamed over packet-switched networks, suchas streaming HDTV broadcasts, these problems become more pronounced.

The above-described description is merely intended to provide acontextual overview regarding streaming media, and is not intended to beexhaustive.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the disclosure can be obtained, a moreparticular description of the principles briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only exemplary embodiments of the disclosure and are nottherefore to be considered to be limiting of its scope, the principlesherein are described and explained with additional specificity anddetail through the use of the accompanying drawings in which:

FIG. 1 illustrates an example system embodiment;

FIG. 2 illustrates an example media streaming architecture;

FIG. 3 illustrates an exemplary set of steps representing interactionsbetween a media playback client and a media streaming server; and

FIG. 4 illustrates an example method embodiment.

DETAILED DESCRIPTION

Various embodiments of the disclosure are discussed in detail below.While specific implementations are discussed, it should be understoodthat this is done for illustration purposes only. A person skilled inthe relevant art will recognize that other components and configurationsmay be used without parting from the spirit and scope of the disclosure.

The approach set forth herein is for automating encoder/decoderselection based on Quality of Service to provide optimal video qualityfor streaming content. Instead of relying solely on changing streamingparameters of an encoder, this approach handles changing networkconditions by changing from one encoder to another, based on conditionssuch as the network quality of service, type of network, type of mediato stream, client preferences, decoders available on the client, and soforth. An encoder and a corresponding decoder can be matched ‘pair’ of acoder/decoder, or codec. The system changes the source media encoder byutilizing an automated selectable multi-codec module that checks thetransmission medium Quality of Service, including parameter such asthroughput, latency, buffer, propagation error, jitter, and so forth.Based on the input media type format, the system compares the inputmedia type to a list of available decoders at the client, and beginsautomatically encoding the media using an optimal codec based on thoseparameters. The client device can receive metadata associated with thereceived encoded stream to command the client device to automaticallyapply a particular decoder from a store of available decoders.Alternatively, the client device can simply identify an encoding type ofthe received encoded stream without the use of metadata, then select andapply the appropriate decoder.

Disclosed are systems, methods, and non-transitory computer-readablestorage media for a media server and for a media client. The mediaserver determines quality of service parameters for a network betweenthe media server and a media client. The quality of service parameterscan include throughput, latency, buffer, propagation, error, jitter, andother network metrics. The quality of service parameters can bedetermined based on information gathered by at least one of the mediaserver, the media client, and a node residing in the network.

The media server selects an encoder based on a list of decodersavailable at the media client and the quality of service parameters, andencodes at least a portion of the media via the encoder for streaming tothe media client. The media server can select the encoder based on aratio of encoder compression output quality to source media quality. Thelist of decoders can be received from the media client or from adatabase lookup, such as a media client device type database indicatingwhich decoders are available for a particular media client softwareand/or hardware revision. Further, the list can indicate whether thedecoders are hardware decoders or software decoders. The media servercan also determine a media profile for media to be transmitted to themedia client, and select the encoder further based on the media profile.The media server can determine settings for the encoder based on themedia type and the quality of service parameters, and encode the mediavia the encoder according to the settings.

In the case of streaming media to a mobile device or other device thatcan change between networks, the media server can detect that the mediaclient has moved to a new network, receive new quality of serviceparameters for the new network, select a new encoder based on the listof decoders available at the media client, the media type, and the newquality of service parameters, and encode the media via the new encoderinstead of the encoder for streaming to the media client through the newnetwork. Similarly, the media server can receive updated quality ofservice parameters for the network, select a new encoder based on thelist of decoders available at the media client, the media type, and theupdated quality of service parameters, and encode the media via the newencoder instead of the encoder for streaming to the media client throughthe network.

The media server can determine an optimal encoder based on the mediatype and the quality of service parameters, but for which a decodercorresponding to the optimal encoder is not on the list of decodersavailable at the media client. In this case, the media server can selecta temporary encoder based on the list of decoders available at the mediaclient, and encode the media via the temporary encoder for streaming tothe media client. Then the media server can instruct the media client toobtain the decoder, such as from the media server or from some othersource. Upon receiving a notification that the media client has obtainedthe decoder, the media server can encode the media via the optimalencoder instead of the temporary encoder for streaming to the mediaclient.

A media client can optionally report a set of available decoders to amedia server or other entity. The media client requests media from themedia server, which selects an encoder based on a type of the media,network quality of service parameters, and the set of decoders. Then themedia client receives from the media server a stream of the media, anddecodes the stream using a decoder, from the set of decoders,corresponding to the encoder to yield decoded media data. The mediaclient outputs the decoded media data, such as on a display. The mediaclient can detect a move to a new network, and report the new network tothe media server. The media client can transmit to the media serverclient parameters for video playback associated with at least one ofprocessor usage, memory usage, battery usage, bandwidth, visual quality,client output capabilities, availability of dedicated decoding hardware,decoder capabilities, licensing, and cost. The media server can receivethe client parameters, and select an encoder further based on the clientparameters.

In this way, the media server and the media client can adapt todifferent network conditions by selecting a different encoder/decoderpair that is based on specific network conditions, and can even switchencoder/decoder mid-stream. Thus, the media server and media client arenot limited to the capabilities of any single encoder/decoder, and canbetter adapt to provide the best media experience possible, given thenetwork and quality of service conditions.

The present disclosure addresses the need in the art for improving andmaintaining quality in streamed media. A brief introductory descriptionof a basic general purpose system or computing device in FIG. 1 whichcan be employed to practice the concepts is disclosed herein. A moredetailed description of media streaming using encoders and decodersselected based on network quality information will then follow. Thesevariations shall be discussed herein as the various embodiments are setforth. The disclosure now turns to FIG. 1.

With reference to FIG. 1, an exemplary system 100 includes ageneral-purpose computing device 100, including a processing unit (CPUor processor) 120 and a system bus 110 that couples various systemcomponents including the system memory 130 such as read only memory(ROM) 140 and random access memory (RAM) 150 to the processor 120. Thesystem 100 can include a cache 122 of high speed memory connecteddirectly with, in close proximity to, or integrated as part of theprocessor 120. The system 100 copies data from the memory 130 and/or thestorage device 160 to the cache 122 for quick access by the processor120. In this way, the cache provides a performance boost that avoidsprocessor 120 delays while waiting for data. These and other modules cancontrol or be configured to control the processor 120 to perform variousactions. Other system memory 130 may be available for use as well. Thememory 130 can include multiple different types of memory with differentperformance characteristics. It can be appreciated that the disclosuremay operate on a computing device 100 with more than one processor 120or on a group or cluster of computing devices networked together toprovide greater processing capability. The processor 120 can include anygeneral purpose processor and a hardware module or software module, suchas module 1 162, module 2 164, and module 3 166 stored in storage device160, configured to control the processor 120 as well as aspecial-purpose processor where software instructions are incorporatedinto the actual processor design. The processor 120 may essentially be acompletely self-contained computing system, containing multiple cores orprocessors, a bus, memory controller, cache, etc. A multi-core processormay be symmetric or asymmetric.

The system bus 110 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. A basicinput/output system (BIOS) stored in ROM 140 or the like, may providethe basic routine that helps to transfer information between elementswithin the computing device 100, such as during start-up. The computingdevice 100 further includes storage devices 160 such as a hard diskdrive, a magnetic disk drive, an optical disk drive, tape drive or thelike. The storage device 160 can include software modules 162, 164, 166for controlling the processor 120. Other hardware or software modulesare contemplated. The storage device 160 is connected to the system bus110 by a drive interface. The drives and the associated computerreadable storage media provide nonvolatile storage of computer readableinstructions, data structures, program modules and other data for thecomputing device 100. In one aspect, a hardware module that performs aparticular function includes the software component stored in anon-transitory computer-readable medium in connection with the necessaryhardware components, such as the processor 120, bus 110, display 170,and so forth, to carry out the function. The basic components are knownto those of skill in the art and appropriate variations are contemplateddepending on the type of device, such as whether the device 100 is asmall, handheld computing device, a desktop computer, or a computerserver.

Although the exemplary embodiment described herein employs the hard disk160, it should be appreciated by those skilled in the art that othertypes of computer readable media which can store data that areaccessible by a computer, such as magnetic cassettes, flash memorycards, digital versatile disks, cartridges, random access memories(RAMs) 150, read only memory (ROM) 140, a cable or wireless signalcontaining a bit stream and the like, may also be used in the exemplaryoperating environment. Non-transitory computer-readable storage mediaexpressly exclude media such as energy, earner signals, electromagneticwaves, and signals per se.

To enable user interaction with the computing device 100, an inputdevice 190 represents any number of input mechanisms, such as amicrophone for speech, a touch-sensitive screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 170 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems enable a user to provide multiple types of input to communicatewith the computing device 100. The communications interface 180generally governs and manages the user input and system output. There isno restriction on operating on any particular hardware arrangement andtherefore the basic features here may easily be substituted for improvedhardware or firmware arrangements as they are developed.

For clarity of explanation, the illustrative system embodiment ispresented as including individual functional blocks including functionalblocks labeled as a “processor” or processor 120. The functions theseblocks represent may be provided through the use of either shared ordedicated hardware, including, but not limited to, hardware capable ofexecuting software and hardware, such as a processor 120, that ispurpose-built to operate as an equivalent to software executing on ageneral purpose processor. For example the functions of one or moreprocessors presented in FIG. 1 may be provided by a single sharedprocessor or multiple processors. (Use of the term “processor” shouldnot be construed to refer exclusively to hardware capable of executingsoftware.) Illustrative embodiments may include microprocessor and/ordigital signal processor (DSP) hardware, read-only memory (ROM) 140 forstoring software performing the operations discussed below, and randomaccess memory (RAM) 150 for storing results. Very large scaleintegration (VLSI) hardware embodiments, as well as custom VLSIcircuitry in combination with a general purpose DSP circuit, may also beprovided.

The logical operations of the various embodiments are implemented as:(1) a sequence of computer implemented steps, operations, or proceduresrunning on a programmable circuit within a general use computer, (2) asequence of computer implemented steps, operations, or proceduresrunning on a specific-use programmable circuit; and/or (3)interconnected machine modules or program engines within theprogrammable circuits. The system 100 shown in FIG. 1 can practice allor part of the recited methods, can be a part of the recited systems,and/or can operate according to instructions in the recitednon-transitory computer-readable storage media. Such logical operationscan be implemented as modules configured to control the processor 120 toperform particular functions according to the programming of the module.For example, FIG. 1 illustrates three modules Mod I 162, Mod 2 164 andMod 3 166 which are modules configured to control the processor 120.These modules may be stored on the storage device 160 and loaded intoRAM 150 or memory 130 at runtime or may be stored as would be known inthe art in other computer-readable memory locations.

Having disclosed some components of a computing system, the disclosurenow returns to a discussion of media streaming. This approachautomatically selects the optimal encoding/decoding/transcoding platformfor uncompressed or previously encoded streaming media. The systemintelligently processes data collected via received input signals fromthe connected device, the media to be encoded for streaming (includingtype and/or format), and input from the connected transmission path thatdescribes Quality of Service via TX/RX monitoring. The system candetermine an optimal codec based on data collected from the sources andtransmission path for the media to be streamed. Once the codec at thesystem is selected, the system begins streaming the media and processingmetadata for causing the proper decoder selection at the media clientdevice. This approach is unique because it strays from the conventionalapproaches of focusing on the transmission medium throughput as theselection for encoding compression level. This approach automaticallyselects an entire codec based on link quality of service and input mediatype. This approach allows for a streaming media end user to receive theabsolute best quality content based off the various codecs and theircompression ratio to source quality.

FIG. 2 illustrates an example media streaming architecture 200. In thisarchitecture 200, a media server 214 streams media content 216 over anetwork 212 to a media client 202 for output on a display 204. Theserver 214 has a set of encoders 218, 220, 222 which it can use toencode media content 216. The encoders can be dedicated encoders or canbe part of a codec package. The client 202 also has decoders 206, 208,210 which it uses to decode encoded streamed media content for playback.The client 202 can be a mobile device such as a smartphone, laptopcomputer, or tablet, a non-mobile device, such as a cable or digitaltelevision set-top box, or other device. The client 202 makes a requestto the server 214, via the network 212, for media content 216. Theclient 202 and the server 214 can perform a handshake to allow theserver 214 to identify which decoders 206, 208, 210 the client 202 hasavailable. The server 214 can explicitly query the types of decodersavailable, or can request other information from which the server 214can infer which types of decoders are available, such as a networkaddress, a client device type, a client software platform and/orrevision, and so forth. The server 214 can use a database of availabledecoders for different types of devices, for example, to determine thata device of type X has decoders Y and Z available. In another example,the server 214 has a database of available decoders for potentialclients, and when a media content request arrives from a particularnetwork address, the server 214 can look up that network address in thedatabase to determine which decoders are available at that client. Thedatabase can be updated as clients add decoders, or as clients are addedor removed.

The server 214 also receives network quality of service information forthe network 212. In one variation, the client 202 sends a quality ofservice ‘burp’, which stands for Bi-directional Universal Rate Ping, tothe server 214 from which the server can determine at least some of thenetwork quality of service information. The serve 214 and/or the client202 can determine and communicate the network quality of serviceinformation in other ways as well, either singly or in cooperation onewith another. Based on the network quality of service information, theserver 214 identifies an optimal encoder from a set of encoders havingcorresponding decoders on the client 202. For example, if the networkquality of service information indicates particularly low throughput,such as 1.5 megabit per second, the server 214 can select an MPEG-4encoder because MPEG-4 can handle very low bandwidth connections andstill present decent video quality. On the other hand, if the networkquality of service information indicates that the network has very lowlatency and high throughput, such as 10 megabits per second, the server214 can select a VC-1 encoder because it can provide high-quality videoat that bit rate.

The server 214 can gauge or detect network quality of serviceinformation in other ways as a replacement for or as a supplement to thequality of service burp. For example, the server 214 can perform its ownnetwork testing, or nodes in the network can report current networkconditions to the server 214. If the server 214 receives data frommultiple sources, the server 214 can intelligently combine that data toconstruct an accurate reflection of network conditions.

Further, the client 202 can send to the server 214 user or devicepreferences for a particular decoder, a particular encoder setting,and/or a particular goal. For example, if the client 202 has a softwaredecoder and a hardware decoder, the hardware decoder may be less taxingon the battery life of the client 202. Thus, in low-battery situations,the client 202 can send a preference to the server 214 for using thehardware decoder, even if the corresponding encoder on the server 214may not be the optimal encoder given the network conditions. Thepreference can also include a preference strength or weight. Forexample, if the video quality using preferred hardware decoder, giventhe network conditions, is below a certain threshold indicated by thepreference strength, then the server can use an encoder corresponding tothe software encoder instead. In this way, the client 202 can indicate apreference, and use the preference strength as a way to indicate how andwhen to make a trade-off between video quality and battery life or otherclient consideration. Similarly, the client 202 may be using or planningto use some of the network resources for a background task, such asdownloading a software update or uploading data to a social network. Inthis case, the client 202 can request that the settings for the selectedencoder use a lower bit rate, either based on an absolute reduction inbit rate or a dynamic reduction in bit rate or other setting.

Then, once the server 214 has selected a codec and appropriate settingsfor that codec, the server 214 progressively encodes portions of themedia content 216 in real time for streaming to the client 202. Theclient 202 receives the encoded media content, decodes the encoded mediacontent using the corresponding decoder, and outputs the decoded contenton the display 204.

If the server 214 or the client 202 detects a change in the networkquality of service information, the server 214 can select a new encoderand/or new settings for streaming the media content if the previouslyselected encoder and/or settings are no longer optimal. The client 202can send periodic burps to the server 214 indicating the quality ofservice, such as every 50 milliseconds or some other interval.Alternately, the client 202 can send a burp or other signal to theserver 214 when network conditions change beyond a threshold, or whenthe client 202 changes from one network to another, such as a mobiledevice switching from a Wi-Fi network to a 3G cellular network. In thesecases, the server 214 can switch from one encoder to another encodermid-stream to continue to provide optimal video quality given thenetwork conditions.

FIG. 3 illustrates an exemplary set of steps representing interactionsbetween a media playback client and a media streaming server. First, themedia playback client sends a media request to the media streamingserver, which the media streaming server receives. Second, the mediaplayback client detects and reports network quality of serviceparameters, and/or the media streaming server determines network qualityof service parameters. The media streaming server can combine andanalyze data, which may or may not overlap, from multiple sources todetermine as complete of a picture of network conditions as possible.Third, the media playback client can report information about availabledecoders on the media playback client. This step can occur at any point,including before the media request. Further, other entities besides themedia playback client can report information about which decoders areavailable on the media playback client, such as an available decoderdatabase service, or a look-up table of available decoders by devicetype. Fourth, the media streaming server selects an optimal encoderand/or optimal settings for the encoder based on the available decoderson the media playback client, and the network quality of serviceparameters. The media streaming server can use a logic table, parameterranges, algorithms, and/or preconfigured settings, for example, todetermine which encoder and which settings are ‘optimal’, and what‘optimal’ means. Optimal can be directed to absolute video quality,video quality given the output capabilities of the media playbackclient, monetarily cheapest to encode and transmit, computationallycheapest to encode and transmit, the maximum quality that can fit withina certain cost and/or bandwidth, which encoders require a license fee,and other factors.

The factors that determine an optimal encoder and settings can beestablished for all clients, or clients/users can establish personalizedfactors and weights for those factors that take in to consideration whata user desires. For example, one user may have an extremely high endaudio system, so his preferences can indicate to only use lossless audioencoding in 7.1 surround sound for video content. Another user may usethe built-in speakers in his HDTV, so his preferences can indicate todown-mix all the audio to stereo and to permit the use of lossyencoding. Further, these settings can be established per user and/or perdevice, to accommodate for user-specific preferences and device-specificabilities and considerations.

Similarly, the media streaming server can select encoders based ondifferent ranges of network quality parameters that are suited todifferent encoders. For example, codec X may apply to a certain highbandwidth and low jitter range, with various parameter changes based onthe actual bandwidth available and the actual jitter experienced. If thebandwidth or jitter drops below a certain threshold into a differentrange of parameters, the system can switch to a different encodercorresponding to that different range. Further, the system can considerthe current encoding of the source media content. If the source mediacontent is already encoded using a non-optimal encoder, such as thesecond choice of encoder based on the network parameters, then thesystem can determine that the extra effort, cost, and computing time totranscode using the optimal encoder would outweigh the incrementalimprovement in quality over the existing encoded media. In this case,the media streaming server can simply transmit the previously encodedmedia, as long as the media playback client has a corresponding decoder.

Fifth, the media streaming server streams encoded media using theoptimal encoder and the optimal settings in response to the mediarequest, and the media playback client receives and decodes the streamedmedia for playback. The media streaming server can encode or transcodemedia content. The principles set forth herein allow streaming media toretain its pre-encoded source quality (for native content) and to betransported greater distances with lower bit rate technologies, such as3G cellular networks, 4G or LTE cellular networks, and/or locallyavailable wireless networks.

Having disclosed some basic system components and concepts, thedisclosure now turns to the exemplary method embodiment shown in FIG. 4.For the sake of clarity, the method is discussed in terms of anexemplary system 100 as shown in FIG. 1 configured to practice themethod as the media server. The steps outlined herein are exemplary andcan be implemented in any combination thereof, including combinationsthat exclude, add, or modify certain steps.

The media server determines quality of service parameters for a networkbetween the media server and a media client (402). The quality ofservice parameters can include throughput, latency, buffer, propagation,error, jitter, and other network metrics. The quality of serviceparameters can be determined based on information gathered by at leastone of the media server, the media client, and a node residing in thenetwork.

The media server selects an encoder based on a list of decodersavailable at the media client and the quality of service parameters(404), and encodes at least a portion of the media via the encoder forstreaming to the media client (406). The media server can select theencoder based on a ratio of encoder compression output quality to sourcemedia quality. The list of decoders can be received from the mediaclient or from a database lookup, such as a media client device typedatabase indicating which decoders are available for a particular mediaclient software and/or hardware revision. Further, the list can indicatewhether the decoders are hardware decoders or software decoders. Themedia server can also determine a media profile for media to betransmitted to the media client, and select the encoder further based onthe media profile. The media server can determine settings for theencoder based on the media type and the quality of service parameters,and encode the media via the encoder according to the settings.

In the case of streaming media to a mobile device or other device thatcan change between networks, the media server can detect that the mediaclient has moved to a new network, receive new quality of serviceparameters for the new network, select a new encoder based on the listof decoders available at the media client, the media type, and the newquality of service parameters, and encode the media via the new encoderinstead of the encoder for streaming to the media client through the newnetwork. Similarly, the media server can receive updated quality ofservice parameters for the network, select a new encoder based on thelist of decoders available at the media client, the media type, and theupdated quality of service parameters, and encode the media via the newencoder instead of the encoder for streaming to the media client throughthe network.

The media server can determine an optimal encoder based on the mediatype and the quality of service parameters, but for which a decodercorresponding to the optimal encoder is not on the list of decodersavailable at the media client. In this case, the media server can selecta temporary encoder based on the list of decoders available at the mediaclient, and encode the media via the temporary encoder for streaming tothe media client. Then the media server can instruct the media client toobtain the decoder, such as from the media server or from some othersource. Upon receiving a notification that the media client has obtainedthe decoder, the media server can encode the media via the optimalencoder instead of the temporary encoder for streaming to the mediaclient.

On the other hand, the media client can optionally report a set ofavailable decoders to a media server or other entity. The media clientrequests media from the media server, which selects an encoder based ona type of the media, network quality of service parameters, and the setof decoders. Then the media client receives from the media server astream of the media, and decodes the stream using a decoder, from theset of decoders, corresponding to the encoder to yield decoded mediadata. The media client outputs the decoded media data, such as on adisplay. The media client can detect a move to a new network, and reportthe new network to the media server. The media client can transmit tothe media server client parameters for video playback associated with atleast one of processor usage, memory usage, battery usage, bandwidth,visual quality, client device output capabilities, availability ofdedicated decoding hardware, decoder capabilities, licensing, and cost.The media server can receive the client parameters, and select anencoder further based on the client parameters.

In this way, the media server and the media client can adapt todifferent network conditions by selecting a different encoder/decoderpair that is based on specific network conditions, and can even switchencoder/decoder mid-stream. Thus, the media server and media client arenot limited to the capabilities of any single encoder/decoder, and canbetter adapt to provide the best media experience possible, given thenetwork and quality of service conditions.

In some variations of this approach, the media server can identify anoptimal encoder which is not available on the client, and a secondencoder which is available on the client. In this case, the media servercan progressively encode the media for streaming to the client forplayback, while a decoder corresponding to the optimal encoder is beingtransmitted to the client. The media server or other entity can providethe decoder to the client. Alternatively, the media server or otherentity can provide a link to the client a link to download the decoder,or other instructions to obtain the decoder. Then, upon receiving asignal that the client has the optimal decoder in place, the mediaserver can transition to the optimal encoder seamlessly. This exampleassumes that the client stores decoders in some kind of storage mediumwhich can be updated to include new decoders. Similarly, the client candownload and install new firmware for a hardware decoder, or a user caninstall a removable device storing a decoder, such as a USB memorydevice or other device having an integrated hardware decoder.

Embodiments within the scope of the present disclosure may also includetangible and/or non-transitory computer-readable storage media forcarrying or having computer-executable instructions or data structuresstored thereon. Such non-transitory computer-readable storage media canbe any available media that can be accessed by a general purpose orspecial purpose computer, including the functional design of any specialpurpose processor as discussed above. By way of example, and notlimitation, such non-transitory computer-readable media can include RAM,ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storageor other magnetic storage devices, or any other medium which can be usedto carry or store desired program code means in the form ofcomputer-executable instructions, data structures, or processor chipdesign. When information is transferred or provided over a network oranother communications connection (either hardwired, wireless, orcombination thereof) to a computer, the computer properly views theconnection as a computer-readable medium. Thus, any such connection isproperly termed a computer-readable medium. Combinations of the aboveshould also be included within the scope of the computer-readable media.

Computer-executable instructions include, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. Computer-executable instructions also includeprogram modules that are executed by computers in stand-alone or networkenvironments. Generally, program modules include routines, programs,components, data structures, objects, and the functions inherent in thedesign of special-purpose processors, etc. that perform particular tasksor implement particular abstract data types.

Computer-executable instructions, associated data structures, andprogram modules represent examples of the program code means forexecuting steps of the methods disclosed herein. The particular sequenceof such executable instructions or associated data structures representsexamples of corresponding acts for implementing the functions describedin such steps. Those of skill in the art will appreciate that otherembodiments of the disclosure may be practiced in network computingenvironments with many types of computer system configurations,including personal computers, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, and the like.

Embodiments may also be practiced in distributed computing environmentswhere tasks are performed by local and remote processing devices thatare linked (either by hardwired links, wireless links, or by acombination thereof) through a communications network. In a distributedcomputing environment, program modules may be located in both local andremote memory storage devices.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the scope of thedisclosure. Those skilled in the art will readily recognize variousmodifications and changes that may be made to the principles describedherein without following the example embodiments and applicationsillustrated and described herein, and without departing from the spiritand scope of the disclosure.

What has been described above includes examples of systems and methodsthat provide advantages of the disclosed subject matter. It is, ofcourse, not possible to describe every conceivable combination ofcomponents or methods for purposes of describing the disclosed subjectmatter, but one of ordinary skill in the art may recognize that manyfurther combinations and permutations of the disclosed subject matterare possible. Furthermore, to the extent that the terms “includes,”“has,” “possesses,” and the like are used in the detailed description,claims, appendices and drawings such terms are intended to be inclusivein a manner similar to the term “comprising” as “comprising” isinterpreted when employed as a transitional word in a claim.

What is claimed is:
 1. A method, comprising: in response to determining,by a media server comprising a processor, that a preferred decoder,selected by the media server to encode media content based upon qualityof service parameters for network equipment communicatively coupling themedia server and the media client, is not available at a media client:encoding, by the media server using a temporary encoder having acorresponding decoder at the media client, a first portion of the mediacontent to generate first encoded media content, and sending, by themedia server, the first encoded media content to the media client. 2.The method of claim 1, further comprising: in response to determining,by media server, that the media client has obtained the preferreddecoder: encoding, by the media server using the preferred encoder, asecond portion of the media content to generate second encoded mediacontent, and sending, by the media server, the second encoded mediacontent to the media client.
 3. The method of claim 1, wherein thequality of service parameters comprise at least one of throughput,latency, buffer, propagation, error, or jitter.
 4. The method of claim1, further comprising selecting, by the media server, the preferredencoder further based on a type of the media content.
 5. The method ofclaim 1, further comprising selecting, by the media server, thepreferred encoder further based on client parameters of the mediaclient.
 6. The method of claim 5, wherein the client parameters comprisea parameter selected from a group of parameters, comprising processorusage, memory usage, bandwidth, visual quality, client outputcapabilities, availability of dedicated decoding hardware, decodercapabilities, licensing, and cost.
 7. The method of claim 1, furthercomprising querying, by the media server, the media client for decodersavailable at the media client.
 8. A system, comprising: a processor; anda memory that stores executable instructions that, when executed by theprocessor, facilitate performance of operations, comprising: in responseto determining that a preferred decoder is not available at a mediaclient, wherein the preferred decoder was selected to encode a videobased upon quality of service parameters for network equipmentcommunicatively coupling the system and the media client: encoding,using a temporary encoder having a corresponding decoder at the mediaclient, a first portion of the video to generate a first encoded videoportion, and facilitating transmitting the first encoded video portionto the media client.
 9. The system of claim 8, wherein the operationsfurther comprise: in response to determining that the media client hasobtained the preferred decoder: encoding, using the preferred encoder, asecond portion of the video to generate a second encoded video portion,and facilitating transmitting the second encoded video portion to themedia client.
 10. The system of claim 8, wherein the quality of serviceparameters comprise at least one of throughput, latency, buffer,propagation, error, or jitter.
 11. The system of claim 8, wherein theoperations further comprise further comprising selecting the preferredencoder further based on a type of the video.
 12. The system of claim 8,wherein the operations further comprise selecting the preferred encoderfurther based on client parameters of the media client.
 13. The systemof claim 12, wherein the client parameters comprise at least one ofprocessor usage, memory usage, bandwidth, visual quality, client outputcapabilities, availability of dedicated decoding hardware, decodercapabilities, licensing, or cost.
 14. The system of claim 8, furthercomprising querying the media client for decoders available at the mediaclient.
 15. A non-transitory machine-readable medium, comprisingexecutable instructions that, when executed by a processor, facilitateperformance of operations, comprising: in response to determining that apreferred decoder is not available at a media client, wherein thepreferred decoder corresponds to the preferred encoder selected toencode media content based upon quality of service parameters fornetwork equipment communicatively coupled to the media client: encoding,using a temporary encoder having a corresponding decoder at the mediaclient, a first portion of the media content to generate first encodedmedia content, and facilitating transmitting the first encoded mediacontent to the media client.
 16. The non-transitory machine-readablemedium of claim 15, wherein the operations further comprise: in responseto determining, by media server, that the media client has obtained thepreferred decoder: encoding, by the media server using the preferredencoder, a second portion of the media content to generate secondencoded media content, and facilitating transmitting the second encodedmedia content to the media client.
 17. The non-transitorymachine-readable medium of claim 15, wherein the quality of serviceparameters comprise at least one of throughput, latency, buffer,propagation, error, or jitter.
 18. The non-transitory machine-readablemedium of claim 15, wherein the operations further comprise selecting,by the media server, the preferred encoder further based on a type ofthe media content.
 19. The non-transitory machine-readable medium ofclaim 15, wherein the operations further comprise selecting, by themedia server, the preferred encoder further based on client parametersof the media client.
 20. The non-transitory machine-readable medium ofclaim 19, wherein the client parameters comprise at least one of a groupof parameters, comprising processor usage, memory usage, bandwidth,visual quality, client output capabilities, availability of dedicateddecoding hardware, decoder capabilities, licensing, and cost.